Multicast over unicast in a network

ABSTRACT

A method is described for receiving a multicast in user devices in a network issuing a request to join a multicast group, identifying multicast data packets associated with the multicast group, monitoring transmissions of the multicast data packets to determine whether the identified multicast data packets are being transmitted in an already established unicast session and establishing a unicast session and processing multicast data packets if an already established unicast session does not exist A method is described for receiving a multicast transmission in user devices in a network establishing a unicast session with a dedicated terminal, identifying multicast data packets associated with a multicast group, monitoring transmissions of the multicast data packets and processing the multicast data packets by the dedicated terminal. Additonally, an apparatus is described for accepting a request to join a multicast group, for identifying multicast data packets associated with the multicast group, establishing a unicast session, for encapsulating said multicast data packets in a unicast frame and for forwarding the unicast frame via the unicast session.

This application claims the benefit, under 35 U.S.C. §365 of

International Application PCT/US04/32963, filed Oct. 6, 2004, which waspublished in accordance with PCT Article 21(2) on Apr. 21, 2005 inEnglish and which claims the benefit of U.S. provisional patentapplication No. 60/509,325, filed Oct. 7, 2003.

FIELD OF THE INVENTION

The present invention relates generally to network communications and,in particular, to a method and apparatus for communicatingbroadcast/multicast data via unicast sessions/connections. The inventionis particularly suitable for implementation in a wireless Local AreaNetwork (WLAN) system operating in accordance with the Institute ofElectrical & Electronics Engineers' (IEEE) 802.11 standards.

BACKGROUND OF THE INVENTION

The context of the present invention is the family of wireless localarea networks or WLANs based upon the IEEE 802.11 standards, whichdefine intermediate devices (IDs) such as access points (APs), bridges,routers and brouters that provide access for mobile devices and to othernetworks, such as hard-wired local area and global networks, such as theInternet. Wireless receiving points utilized in access broadcast videostreaming may include a set top box in a simple system, whereas incommercial rebroadcast system a transcoder /multiplexer/demultiplexer orTMD may operate in conjunction with a local video server. In receivingInternet data, a common gateway operating in a conventional InternetProtocol/Transmission Control ProtocolfUser Datagram Protocol(IP/TCP/UDP) protocol may be utilized.

Conventionally, the IEEE 802.11 based architecture is comprised ofseveral components and services that interact to provide stationmobility transparent to the higher layers of the network stack. The IEEE802.11 based network defines a station as the component that connects toa wireless medium and contains the functionality of the IEEE 802.11protocols, that being MAC (Medium Access Control), PHY (Physical Layer),and a connection to the wireless media. Typically, the IEEE 802.11protocols are implemented in the hardware and/or software of a networkinterface card (NIC).

The IEEE 802.11 standards also define a Basic Service Set or BSS, whichis regarded as a basic building block in WLAN architecture. The BSSconsists of a group of any number of ID stations that communicate withone another. In an independent BSS, the mobile stations communicatedirectly with each other. In an infrastructure BSS, all stations in theBSS communicate with the ID and no longer communicate directly with theindependent BSS, such that all frames are relayed between stations bythe ID.

A station could be a laptop PC, handheld device, or an AP. Stations maybe mobile, portable, or stationary and all stations support the IEEE802.11 station services of authentication, de-authentication, privacy,and data delivery.

If the broadcast or multicast originator is a mobile terminal, broadcastor multicast data are first transferred from the mobile terminal to theID in a unicast transmission. In general, a broadcast transmission is atransmission from one to all; a multicast transmission is a transmissionfrom one to many; and a unicast transmission is from one to one.Hereinafter, broadcast and multicast will be used interchangeably.According to the IEEE 802.11 specifications, the broadcast/multicastmessage may be distributed into the BSS by the ID. Regardless of thelength of the frame, no RTS/CTS exchange can be used. In addition, noACK is permitted to be transmitted to the ID by any of the recipients ofthe multicast/broadcast frame(s). There is no MAC-level recovery onbroadcast or multicast frames sent from the ID.

Video transmissions—in particular real time transmissions—requirebroadcast/multicast transmissions over a network, e.g., over a WLAN.However, broadcast/multicast transmissions suffer from an inherent lackof an error correction mechanism. When a data packet is sent to a groupof receivers (broadcast/multicast), it is extremely difficult, if notimpossible for the transmitter to manage the retransmission protocol foreach receiver.

Several mechanisms exist to overcome the data packet loss in a network,in particular in a WLAN, such as automatic forward error correction(FEC), multicast automatic repeat request (ARQ) etc. All of thesemechanisms, however, suffer from significant added complexity andlimitations in certain network products. For example, some WLANintermediate devices like an Access Point (AP) or a bridge, where bridgeand/or AP are used herein to include router and/or brouter or any devicehaving equivalent functionality, have an inherent limit in thetransmission rate for WLAN multicast data packets on the premise thatmulticast quality should be limited by the client, e.g., mobile terminalwith the poorest reception (i.e., the client that is farthest away fromthe ID). Such a limitation dictates that even if a client is close tothe ID there is no possibility for any QoS upgrade of the multicastquality.

SUMMARY OF THE INVENTION

The present invention offers network multicast/broadcast services usingunicast sessions thereby profiting from the ARQ-based error correctionmechanism used for a unicast connection to enhance the quality ofmulticast/broadcast communications to neighboring users. If a unicastsession exists that uses ARQ-based error correction, then neighboringusers can listen in on the unicast session and profit from the ARQmechanism without requiring any additional unicast sessions to beinitiated and maintained. Thus, normal unicast mechanisms can beleveraged to provide multicast/broadcast services without complex FEC ormulticast ARQ schemes. Additionally, it is possible to accommodate aplurality of transmission rates, e.g., 1 Mbps, 2 Mbps, 5.5 Mbps and 11Mbps. Hereinafter, the terms session and connection will be usedinterchangeably.

This plurality of transmission rates also addresses the near/farproblem. The near/far problem is the term used to indicate that thethroughput rate is lower at the edges of the cell (far) and highercloser to the intermediate device (near) and that the error correctionschemes are, therefore, also different. The UDP traffic is assumed to bebroadcast/multicast (e.g., video multicast). In the present invention,the UDP broadcast/multicast data packets are encapsulated into Ethernetframes for transmission via unicast sessions/connections.

A method is described for receiving a multicast in user devices in anetwork issuing a request to join a multicast group, identifyingmulticast data packets associated with the multicast group, monitoringtransmissions of the multicast data packets to determine whether theidentified multicast data packets are being transmitted in an alreadyestablished unicast session and establishing a unicast session andprocessing multicast data packets if an already established unicastsession does not exist. A method is described for receiving a multicasttransmission in user devices in a network establishing a unicast sessionwith a dedicated terminal, identifying multicast data packets associatedwith a multicast group, monitoring transmissions of the multicast datapackets and processing the multicast data packets by the dedicatedterminal.

Additionally, an apparatus is described for accepting a request to joina multicast group, for identifying multicast data packets associatedwith the multicast group, establishing a unicast session, forencapsulating said multicast data packets in a unicast frame and forforwarding the unicast frame via the unicast session. Additionally, anapparatus is described for establishing a unicast session with amulticast-to-unicast converter, for identifying multicast data packetsassociated with a multicast group, for encapsulating the multicast datapackets in a unicast frame and for forwarding the unicast frames via theunicast session.

A method and apparatus are described for receiving a multicast/broadcastin user devices in a network, comprising receiving, by an intermediatedevice (ID), a request from a first user device to join a multicastgroup, identifying multicast/broadcast data packets associated with themulticast group, monitoring transmissions of the multicast/broadcastdata packets from the ID, by the first user device, to determine whetherthe identified multicast/broadcast data packets are being transmittedbetween the ID and a second user device in an already establishedunicast session/connection between the second user device and the ID,processing the multicast/broadcast data packets by the second userdevice, if the second user device is in the already established unicastsession/connection between the second user device and the ID andestablishing a unicast session/connection between the first user deviceand the ID and switching to normal mode and processingmulticast/broadcast data packets by the first user device, if one of thesecond user device is not in the already established unicastsession/connection and the first user device is no longer in a coveragearea for receiving transmissions between the second user device and theID. Further, testing to determine if the user device is still active. Ifthe user device is still active then continuing to receive and processmulticast data packets by the user device. If the user device is notactive then selecting a new user device by the ID and establishing aunicast session/connection with the newly selected user device. Thenewly selected user device switching to normal mode and receiving andprocessing multicast data packets via the newly established unicastsession/connection.

In an alternative embodiment that supports multiple multicasttransmission rate and the uses of dedicated terminals, a wake-up messageis used to determine if the dedicated terminal is still active. Alsosince at least one dedicated terminal is used, there is no necessity towait for an IGMP request for transmission of multicast packets to takeplace. Once a unicast session/connection is established with the atleast one dedicated terminal then transmission of multicast data packets(encapsulated as Ethernet frames) occurs. Other user devices that jointhe multicast group can simply listen in on the unicastsession(s)/connection(s). Multiple unicast sessions/connections supportmultiple transmission rates and may be established by establishingmultiple unicast sessions between the ID.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is best understood with reference to the DetailedDescription of the Preferred Embodiments and the drawings where:

FIG. 1 illustrates an exemplary digital video and audio system suitablefor implementing the present invention;

FIG. 2 is a block diagram of the present invention;

FIG. 3 is a block diagram of an exemplary system in which the presentinvention may be implemented; and

FIGS. 4A and 4B are flowharts illustrating the methods of theembodiments of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 illustrates an exemplary digital video and audio system suitablefor implementing the present invention. At the head end a multiple videoand audio content stream is converted into a digital format (typicallyin accordance with the MPEG-2 standard) and transmitted via, forexample, satellite to a receiving dish, or other suitable means, whichis attached to a receiver referred to as a set top box or other suitablemeans such as a TMD. U.S. Pat. No. 6,510,519, describes a representativesystem utilizing a head end and a set top box including tuners,de-modulators, decoders, transport de-multiplexers, microprocessors,program memories, video picture memories, MPEG video decoders, displays,and smart cards. Most digital broadcast system data streams are encodedand scrambled for security purposes at a transmitter, once decryptionand decoding occur at a receiver, the system builds a video compositepicture in memory and displays the desired picture synchronized with itsaudio component on a monitor. In addition to descrambling the program,generally, further authorizations are provided to insure that theparticular receiver has been enabled to receive a program or a set ofprograms.

As further illustrated in FIG. 1, the TMD operating in conjunction witha local video server may be designed and configured to furthercommunicate with a video LAN and a wireless AP, which in theillustrative example provides down line receivers with demultiplexedvideo and audio transmission streams including synchronized signalsnecessary for the transmission of the video and audio content.

The present invention provides error correction for multicast sessionsover a WLAN requiring only one WLAN unicast session/connection. In apublic hot spot like an airport, a restaurant or a lobby of a hotel, itis possible to locate an intermediate device in such a way that thecharacteristics of the wireless channel are nearly identical for a groupof user devices using for example, mobile terminals/mobile devices(MTs/MDs) co-located or in sight of each other. If, at least one unicastsession/connection exists between the ID and one user device, then dueto the inherent usage of the MAC ARQ mechanism, the quality of thetransmission is good. The other user devices are then able to capturethe traffic related to the unicast session without the need toeffectively communicate with the ID. That is, additional unicastsessions need not be initiated or maintained.

A video source communications is broadcast towards an ID from e.g., avideo server. It is assumed that the video source is amulticast/broadcast source where the destination IP packet discerns thebroadcast/multicast IP address Ma1 of the multicast group M1. The IDblocks the packets until a user device expresses its intention toreceive the broadcast/multicast data packets. The user device T1initiates an application A1 that is ready to process incoming datapackets relative to the multicast group M1. T1 sends an IGMP messagetowards the network (thus, to/through the ID) that is a request to beassociated with the group M1. The ID receives the IGMP message and sincethis user device is the first element requesting association with themulticast group M1, the ID forwards the IP multicast data packets usingas the MAC destination address (the MAC address of the user device) T1.

Normally, a multicast IP address is converted to a multicast EthernetMAC address. An IEEE 802.11 user device processing a packet, determineswhether the destination address is a multicast address. If the addressis a multicast data packet then the user device cannot use the MAC ARQmechanism. In the present invention, the multicast/broadcast datapackets are encapsulated in Ethernet frames for transmission via aunicast session/connection. The inner IP data packet contains theunchanged IP multicast group address Ma1. The outer IP data packetcontains the unicast destination address of user device T1. The userdevice T1 receives the IP data packets. In case of a transmission error,retransmission is possible through the IEEE 802.11 MAC ARQ mechanism.

A second terminal T2 initiates an application A2 that requestsassociation with the same group M1. T2 first listens (T2 needs then toswitch its wireless network interface card (NIC) into monitor mode inwhich all packets (whatever the destination address) are captured by theNIC and delivered to the upper layer (usually the driver)) by thechannel dedicated to the video streaming and searches for a sessioncarrying IP data packets for which the destination address correspondsto the multicast group address Ma1. Because such packets exist, T2remains in monitor mode listening to the corresponding data packets. Incase of packet loss, based on the assumption that the error distributionpattern is very close between neighbor user devices, user device T2 alsoreceives the repeated packets sent from the ID to T1.

In the event that the unicast session is broken/ended because the userdevice disassociates (leaves the cell), there is a need for a mechanismto select/designate/locate a new unicast session user device(counterpart) for the ID. Once a new user device islocated/chosen/designated, the ID forwards the video related datapackets in unicast mode (i.e. the destination MAC address corresponds tothe new selected unicast counterpart) to the newlyselected/designated/located user device. The newly designated userdevice would normally be in monitor mode listening to all the incomingdata packets relative to the IP multicast group (M1). Once the newlydesignated user device detects/determines that the data packets areaddressed to itself (by scanning the IEEE 802.11 header), the userdevice switches to the normal mode (i.e. non-monitor mode) and processesthe data packet normally. This switching should take place as quickly aspossible in order to reduce the adverse visual effects that could betriggered by any delay in the switching.

The present invention can be adapted for other radio wireless LANtechnology as Hiperian2. The present invention can also be adapted forcable networks and 3G cellular networks that support broadcast services.An ARQ mechanism at the MAC layer and the ability to switch betweenmonitor mode and normal mode is all that is required for the presentinvention to operate with other wireless LAN technologies.

In an alternative embodiment that addresses the problem of the userdevice that is communicating via the unicast session leaving the cell, adedicated terminal could be designated. The only function of thededicated terminal is to run the MAC protocol. The ID establishes theunicast session with this dedicated terminal. Other/additional dedicatedterminals may be located elsewhere in order to handle the multi-ratecapability of the WLAN radio technology or to provide a back-up in theevent that the first dedicated terminal fails. Several schemes are knownin the art to detect failed terminals and switch to a back-up terminal.

The present invention has been described above as embedded in the ID.However, in an alternative embodiment the present invention may beimplemented outside of the ID. Considering the ID a bridge, themulticast-to-unicast converter needs to be located on the same LocalArea Network (LAN) as the ID. The multicast-to-unicast converter can,however, be located in the video server if the video server is unique orthe multicast-to-unicast converter can be located in a separate andindependent device.

The multicast-to-unicast converter is configured with two interfaces:one connecting the converter with the ID of the network and the otherinterface connecting the converter with the video server(s). Themulticast-to-unicast converter functions in the following manner:

-   -   The converter blocks multicast/broadcast data packets coming        from the video servers until an IGMP request is detected.    -   Upon receipt of a first IGMP request received from the network        via the ID, the converter forwards the corresponding IP        multicast data packet encapsulated into unicast Ethernet frames        (for a unicast session) with a destination address corresponding        to the source address of the received IGMP packet.    -   A drawback of an external multicast-to-unicast converter is        that, being outside the ID, the converter has no knowledge of        the MAC and does not know whether the unicast terminal is still        available (i.e., if ARQ is running with that terminal or not).        Only the ID has that knowledge. A solution to the problem is to        use one or more (at least one) dedicated terminals known in        advance by the converter. The dedicated terminal that is        involved in the unicast MAC session with the ID sends a wake-up        message regularly to the converter. If the converter does not        receive such message after a predetermined time then the        converter forwards the multicast/broadcast IP data packets to        another dedicated terminal.

In a WLAN that offers multicast services, it is desirable to havemultiple multicast sessions with different levels or qualities ofservice (QoS). For clients that can get clear signal from the WLAN ID,the multicast quality can be higher and at a higher rate. For clientsthat are, in general further from the ID and have poor reception, only alower rate will be supported. For example, in IEEE 802.11b based WLAN, 4different modulation schemes and thus rates are supported. The supportedrates are 1 Mbps, 2 Mbps, 5.5 Mbps and 11 Mbps. Although not defined inthe standard, some wireless LAN IDs limit the transmission rate for anymulticast sessions to a fixed low rate on the premise that multicastclients may have drastically different reception quality and a low ratethat can accommodate most clients should be chosen. There are no suchrestrictions on unicast sessions/connections. In the present invention,since multicast services are offered using unicast sessions/connections,multiple multicast (actually unicast) sessions each with different ratesare easily supported. These rates are not statically allocated, butrather depend on whether there are clients that require and can supportsuch rates. For example, if all clients are close to the ID, a multicastsession with 5.5 Mbps may be supported. But if some clients move furtheraway from the ID, a new “multicast” (actually a unicast) session at alower rate e.g., 1 Mbps rate, may be initiated.

FIG. 3 is a block diagram illustrating a computer system 100 to whichthe present invention may be applied, according to an illustrativeembodiment of the present invention. The computer processing system 100may be embodied in a mobile device used to access a cellular network ora WLAN. The computer processing system 100 includes at least oneprocessor (CPU) 102 operatively coupled to other components via a systembus 104. A read only memory (ROM) 106, a random access memory (RAM) 108,a display adapter 110, an I/O adapter 112, a user interface adapter 114,a sound adapter 170, and a network adapter 198, are operatively coupledto the system bus 104.

A display device 116 is operatively coupled to system bus 104 by displayadapter 110. A disk storage device (e.g., a magnetic or optical diskstorage device) 118 is operatively coupled to system bus 104 by I/Oadapter 112.

A mouse 120 and keypad/keyboard 122 are operatively coupled to systembus 104 by user interface adapter 114. The mouse 120 and keyboard 122are used to input and output information to and from system 100.

At least one speaker (herein after “speaker”) 185 is operatively coupledto system bus 104 by sound adapter 170.

A (digital and/or analog) modem 196 is operatively coupled to system bus104 by network adapter 198.

FIG. 4A is a flowchart of the functions performed by amulticast-to-unicast converter in accordance with the present invention.In this embodiment of the present invention, the multicast-to-unicastconverter is assumed to be embedded in the ID. The converter blocksmulticast data packets coming from the video server(s) until a firstIPMG request is received. Once the first IPMG request is received, thenmulticast data packets received from the network are encapsulated intoEthernet frames (for a unicast session) with a destination addresscorresponding to the source address of the received IGMP request. A testis then made periodically to verify that the user device is stillactive. If the user device is still active (the user device has not leftthe cell or failed) then multicast data packets continue to beforwarded. If, however, the user device is not still active (the userdevice has failed or left the cell) then a new user device must belocated/selected/designated and the multicast data packets will beforwarded to the newly selected/designated/located user device. The userdevice will receive and process the data packets once the user deviceswitches from monitor mode to normal mode.

FIG. 4B is a flowchart of the functions performed by amulticast-to-unicast converter external to the ID. The main differenceis receiving wake-up (watchdog timer) message or not. In this embodimentof the present invention, the multicast-to-unicast converter is assumedto be external to the ID. A dedicated terminal known in advance to theID is used for the unicast session for receiving and processingmulticast data packets. The multicast data packets encapsulated intoEthernet frames (for the unicast session) are forwarded to the dedicatedterminal. A test is then made periodically to verify that the dedicatedterminal is still active (wake-up message received). If the dedicatedterminal is still active (the dedicated terminal has not failed—thewake-up message has been received) then multicast data packets continueto be forwarded. If, however, the dedicated terminal is not still active(the dedicated terminal has failed—the wake-up message has not beenreceived) then a new dedicated terminal must be selected/designated andthe multicast data packets will be forwarded to the newlyselected/designated dedicated terminal. The newly selected dedicatedterminal will receive and process the data packets once the newlyselected dedicated terminal switches from monitor mode to normal mode. Adedicated terminal is used in this embodiment of the invention becausethe multicast-to-unicast converter would not otherwise have anyknowledge of the MAC address since it is external to the LAN. Adedicated terminal would also be used when it is desirable to supportmultiple multicast (actually unicast) sessions/connections havingdifferent transmission rates.

It is to be understood that the present invention may be implemented inhardware, software or firmware or any combination thereof. It is to befurther understood that, because some of the constituent systemcomponents and method steps depicted in the accompanying figures may beimplemented in software, the actual connections between the systemcomponents (or the process steps) may differ depending upon the mannerin which the present invention is programmed. Given the teachingsherein, one of ordinary skill in the related art will be able tocontemplate these and similar implementations or configurations of thepresent invention.

It is to be understood that the form of this invention as shown ismerely a preferred embodiment. Various changes may be made in thefunction and arrangement of parts; equivalent means may be substitutedfor those illustrated and described; and certain features may be usedindependently from others without departing from the spirit and scope ofthe invention as defined in the following claims. For example, althoughthe invention is described in the context of IEEE 802.11 based WLANs, itis to be understood that the invention may be applied to structuresbased on other wireless LAN standards and formats that utilize theprinciples described above.

1. A method for receiving a multicast transmission in user devices in a network, the method comprising: receiving, by an intermediate device, a request from a first user device to join a multicast group; identifying multicast data packets associated with said multicast group; monitoring transmissions of said multicast data packets from said intermediate device, by said first user device operating in monitor mode, to determine whether said identified multicast data packets are being transmitted between said intermediate device and a second user device in an already established unicast session between said second user device and said intermediate device, the already established unicast session comprising the multicast data packets encapsulated in frames for unicast transmission; capturing said multicast data packets by said first user device, without the need to communicate with the intermediate device, if said second user device is in said already established unicast session between said second user device and said intermediate device; and establishing a unicast session between said first user device and said intermediate device and switching to normal mode and processing multicast data packets by said first user device, if one of a) said second user device is not in said already established unicast session and b) said first user device is no longer in a coverage area for receiving transmissions between said second user device and said intermediate device.
 2. The method according to claim 1, further comprising: testing to determine if said second user device is still active; and performing one of continuing to receive multicast data packets via one of said established unicast session and selecting a third user device by said intermediate device with which said intermediate device establishes a new unicast session.
 3. The method according to claim 1, wherein said transmission of multicast data packets occurs in one of a wireless local area network, a cable network and a 3G cellular network that supports broadcast services.
 4. The method according to claim 1, wherein all user devices in said multicast group operate in monitor mode except said user device that is active in said unicast session, said user device that is active in said unicast session operates in normal mode.
 5. The method according to claim 1, wherein said request to join said multicast group is made via an Internet group management protocol request.
 6. A method for receiving a multicast transmission in user devices in a network, the method comprising: establishing a unicast session between an intermediate device and a dedicated terminal, the unicast session comprising multicast data packets encapsulated in frames for unicast transmission; identifying multicast data packets associated with a multicast group; monitoring transmissions of said multicast data packets between said intermediate device and said dedicated terminal by user devices operating in monitor mode without the need to communicate with the intermediate device; testing to determine if a wake-up message is received from said dedicated terminal; if said wake-up message is received, continuing to receive multicast data packets via said already established unicast session, and if said wake-up message is not received, selecting another dedicated terminal by said intermediate device with which said intermediate device establishes a new unicast session; and processing said multicast data packets by said dedicated terminal.
 7. The method according to claim 6, wherein said transmission of multicast/broadcast data packets occurs in one of a wireless local area network, a cable network and a 3G cellular network that supports broadcast services.
 8. The method according to claim 6, wherein all user devices in said multicast group operate in monitor mode and said dedicated terminal operates in normal mode.
 9. The method according to claim 6, wherein a plurality of unicast sessions are established in order to support multiple transmission rates.
 10. The method according to claim 9, wherein said plurality of unicast sessions are between said intermediate device and a plurality of dedicated terminals.
 11. The method according to claim 6, wherein said intermediate device is one of an access point, a bridge, a router and a brouter.
 12. A multicast-to-unicast converter embedded in an intermediate device of a network; means for receiving, by said intermediate device, a request from a first user device to join a multicast group; means for identifying multicast data packets associated with said multicast group; means for monitoring transmissions of said multicast data packets from said intermediate device by said first user device without the need to communicate with the intermediate device to determine whether said identified multicast data packets are being transmitted between said intermediate device and a second user device in an already established unicast session between said second user device and said intermediate device, the unicast session comprising multicast data packets encapsulated in frames for unicast transmission; means for processing said multicast data packets by said second user device, if said second user device is in said already established unicast session between said second user device and said intermediate device; and means for establishing a unicast session between said first user device and said intermediate device and switching to normal mode and processing multicast data packets by said first user device, if one of a) said second user device is not in said already established unicast session and b) said first user device is no longer in a coverage area for receiving transmissions between said second user device and said intermediate device.
 13. The apparatus according to claim 12, further comprising: means for testing to determine if said second user device is still active; and means for performing one of a) continuing to receive multicast data packets via said established unicast session and b) selecting another user device by said intermediate device with which said intermediate device establishes a new unicast session.
 14. The apparatus according to claim 12, wherein said transmission of multicast data packets occurs in one of a wireless local area network, a cable network and a 3G cellular network that supports broadcast services.
 15. The apparatus according to claim 12, wherein all user devices in said multicast group operate in monitor mode except said user device that is active in said unicast session, said user device that is active in said unicast session operates in normal mode.
 16. The apparatus according to claim 12, wherein said request to join said multicast group is made via an Internet group management protocol request. 